Hi

In cases where I need to store the session id and/or the remote host in
a database I used to choose tinytext fields so far. Anyway the usual
values for session ids are of 32 characters length, and IP addresses not
longer than 15 characters - so using char(32) resp. char(15) would
actually improve the database performance. But I did not find
informations whether this is safe or not.

So my questions are:
- Is a PHP session id always 32 characters long (if it is generated
normally with session_start() of course), or can it's format vary due to
PHP versions or configurations (I work in shared hosting envirnoments)?
- Can I safely expect $_SERVER['REMOTE_ADDR'] to deliver an IP address
of the format xxx.xxx.xxx.xxx, or can this also be an IPV6 address or other?

Thanks for a clarification!
Markus

Markus wrote:

> - Can I safely expect $_SERVER['REMOTE_ADDR'] to deliver an IP address
> of the format xxx.xxx.xxx.xxx, or can this also be an IPV6 address or
> other?

Yeah - you can expect it.
But that doesn't mean the IP address is correct.
That's the easiest thing of all for malicious users to spoof.

Markus wrote:

> - Can I safely expect $_SERVER['REMOTE_ADDR'] to deliver an IP address
> of the format xxx.xxx.xxx.xxx, or can this also be an IPV6 address or
> other?

Yeah - you can expect it.
But that doesn't mean the IP address is correct.
That's the easiest thing of all for malicious users to spoof.

Markus wrote:
> Hi
>
> In cases where I need to store the session id and/or the remote host in
> a database I used to choose tinytext fields so far. Anyway the usual
> values for session ids are of 32 characters length, and IP addresses not
> longer than 15 characters - so using char(32) resp. char(15) would
> actually improve the database performance. But I did not find
> informations whether this is safe or not.
>
> So my questions are:
> - Is a PHP session id always 32 characters long (if it is generated
> normally with session_start() of course), or can it's format vary due to
> PHP versions or configurations (I work in shared hosting envirnoments)?

Currently it's 32 characters long. That's not to say it can't change in
future releases.

> - Can I safely expect $_SERVER['REMOTE_ADDR'] to deliver an IP address
> of the format xxx.xxx.xxx.xxx, or can this also be an IPV6 address or
> other?
>

Unlike other comments, $_SERVER['REMOTE_ADDR]' cannot be forged in a
useful manner. It comes directly from the ip header. It is also the ip
address where the response would be sent. And while theoretically it
could be forged, this requires hacking into the ip stack itself, not
just a simple script or browser change - much more complicated than
forging some of the other header values (like HTTP_REFERER). And it's
really only useful for a DOS attack.

But this can can be an IPV6 address if/when your hosting company goes
that way.

> Thanks for a clarification!
> Markus


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex [at] attglobal.net
==================

Markus wrote:
> Hi
>
> In cases where I need to store the session id and/or the remote host in
> a database I used to choose tinytext fields so far. Anyway the usual
> values for session ids are of 32 characters length, and IP addresses not
> longer than 15 characters - so using char(32) resp. char(15) would
> actually improve the database performance. But I did not find
> informations whether this is safe or not.
>
> So my questions are:
> - Is a PHP session id always 32 characters long (if it is generated
> normally with session_start() of course), or can it's format vary due to
> PHP versions or configurations (I work in shared hosting envirnoments)?

Currently it's 32 characters long. That's not to say it can't change in
future releases.

> - Can I safely expect $_SERVER['REMOTE_ADDR'] to deliver an IP address
> of the format xxx.xxx.xxx.xxx, or can this also be an IPV6 address or
> other?
>

Unlike other comments, $_SERVER['REMOTE_ADDR]' cannot be forged in a
useful manner. It comes directly from the ip header. It is also the ip
address where the response would be sent. And while theoretically it
could be forged, this requires hacking into the ip stack itself, not
just a simple script or browser change - much more complicated than
forging some of the other header values (like HTTP_REFERER). And it's
really only useful for a DOS attack.

But this can can be an IPV6 address if/when your hosting company goes
that way.

> Thanks for a clarification!
> Markus


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex [at] attglobal.net
==================

Jerry Stuckle schrieb:
>> - Is a PHP session id always 32 characters long (if it is generated
>> normally with session_start() of course), or can it's format vary due
>> to PHP versions or configurations (I work in shared hosting
>> envirnoments)?
>
> Currently it's 32 characters long. That's not to say it can't change in
> future releases.
So as I use it only for temporary data, such as shopping cart orders or
administrator activities, I assume it is a good idea to work with
substr(session_id(), 0, 32);

>> - Can I safely expect $_SERVER['REMOTE_ADDR'] to deliver an IP address
>> of the format xxx.xxx.xxx.xxx, or can this also be an IPV6 address or
>> other?
>
> Unlike other comments, $_SERVER['REMOTE_ADDR]' cannot be forged in a
> useful manner. It comes directly from the ip header. It is also the ip
> address where the response would be sent. And while theoretically it
> could be forged, this requires hacking into the ip stack itself, not
> just a simple script or browser change - much more complicated than
> forging some of the other header values (like HTTP_REFERER). And it's
> really only useful for a DOS attack.
>
> But this can can be an IPV6 address if/when your hosting company goes
> that way.
To be honest, I never understood what is the point in collecting this
value at all, it just had been there in the first sample script I got
from my first PHP teacher years ago...

Thanks a lot for your helpful info!
Markus

Markus wrote:
> Jerry Stuckle schrieb:
>>> - Is a PHP session id always 32 characters long (if it is generated
>>> normally with session_start() of course), or can it's format vary due
>>> to PHP versions or configurations (I work in shared hosting
>>> envirnoments)?
>>
>> Currently it's 32 characters long. That's not to say it can't change
>> in future releases.
> So as I use it only for temporary data, such as shopping cart orders or
> administrator activities, I assume it is a good idea to work with
> substr(session_id(), 0, 32);

If you try to insert a longer string into the database than the column allows,
it will automatically be turnicated to the max length for the column, so you
don't have to use substr more when you compare the two values. Of you just
assume it's 32 characters long until the day you notice it don't anymore work,
when you ALTER the table to give more space for session id's.


>>> - Can I safely expect $_SERVER['REMOTE_ADDR'] to deliver an IP
>>> address of the format xxx.xxx.xxx.xxx, or can this also be an IPV6
>>> address or other?
>
> To be honest, I never understood what is the point in collecting this
> value at all, it just had been there in the first sample script I got
> from my first PHP teacher years ago...

The vast majority of users will have one and the same IP-number each time they
request a page during the same session, so you can use that ip-number to check
if the request comes from the same machine or not, it you get another ip, you
can assume that someone has managed to sniff the session id and trying to take
over that session, then you could terminate the session and request for the
user to login once more.

If you feel it's overkill, then remove the whole thing, no point in keeping a
IP-number in a database if you not gona use it.

--

//Aho

Markus wrote:
> Jerry Stuckle schrieb:
>>> - Is a PHP session id always 32 characters long (if it is generated
>>> normally with session_start() of course), or can it's format vary due
>>> to PHP versions or configurations (I work in shared hosting
>>> envirnoments)?
>>
>> Currently it's 32 characters long. That's not to say it can't change
>> in future releases.
> So as I use it only for temporary data, such as shopping cart orders or
> administrator activities, I assume it is a good idea to work with
> substr(session_id(), 0, 32);
>

Why even worry about the session id? Just let PHP handle it. You don't
want to store the session id in a database - the data will be gone soon,
anyway. Then you're left with a session id in the database but no
session to go with it.

>>> - Can I safely expect $_SERVER['REMOTE_ADDR'] to deliver an IP
>>> address of the format xxx.xxx.xxx.xxx, or can this also be an IPV6
>>> address or other?
>>
>> Unlike other comments, $_SERVER['REMOTE_ADDR]' cannot be forged in a
>> useful manner. It comes directly from the ip header. It is also the
>> ip address where the response would be sent. And while theoretically
>> it could be forged, this requires hacking into the ip stack itself,
>> not just a simple script or browser change - much more complicated
>> than forging some of the other header values (like HTTP_REFERER). And
>> it's really only useful for a DOS attack.
>>
>> But this can can be an IPV6 address if/when your hosting company goes
>> that way.
> To be honest, I never understood what is the point in collecting this
> value at all, it just had been there in the first sample script I got
> from my first PHP teacher years ago...
>
> Thanks a lot for your helpful info!
> Markus


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex [at] attglobal.net
==================

J.O. Aho wrote:
> Markus wrote:
>> Jerry Stuckle schrieb:
>>>> - Is a PHP session id always 32 characters long (if it is generated
>>>> normally with session_start() of course), or can it's format vary
>>>> due to PHP versions or configurations (I work in shared hosting
>>>> envirnoments)?
>>>
>>> Currently it's 32 characters long. That's not to say it can't change
>>> in future releases.
>> So as I use it only for temporary data, such as shopping cart orders
>> or administrator activities, I assume it is a good idea to work with
>> substr(session_id(), 0, 32);
>
> If you try to insert a longer string into the database than the column
> allows, it will automatically be turnicated to the max length for the
> column, so you don't have to use substr more when you compare the two
> values. Of you just assume it's 32 characters long until the day you
> notice it don't anymore work, when you ALTER the table to give more
> space for session id's.
>
>
>>>> - Can I safely expect $_SERVER['REMOTE_ADDR'] to deliver an IP
>>>> address of the format xxx.xxx.xxx.xxx, or can this also be an IPV6
>>>> address or other?
>>
>> To be honest, I never understood what is the point in collecting this
>> value at all, it just had been there in the first sample script I got
>> from my first PHP teacher years ago...
>
> The vast majority of users will have one and the same IP-number each
> time they request a page during the same session, so you can use that
> ip-number to check if the request comes from the same machine or not, it
> you get another ip, you can assume that someone has managed to sniff the
> session id and trying to take over that session, then you could
> terminate the session and request for the user to login once more.
>

Mostly true. But man users can change IP addresses each time because
they are using a pool of proxy servers. AOL is a great example of this,
but there are others.

And most corporations have a firewall and everyone behind the firewall
uses the same IP address. So you could have hundreds or even thousands
of people using the same IP address.

> If you feel it's overkill, then remove the whole thing, no point in
> keeping a IP-number in a database if you not gona use it.
>

Sessions are not security. If you need security, use a secure protocol.
Then you won't have a problem with sniffing session id's.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex [at] attglobal.net
==================

Jerry Stuckle schrieb:
>> - Is a PHP session id always 32 characters long (if it is generated
>> normally with session_start() of course), or can it's format vary due
>> to PHP versions or configurations (I work in shared hosting
>> envirnoments)?
>
> Currently it's 32 characters long. That's not to say it can't change in
> future releases.
So as I use it only for temporary data, such as shopping cart orders or
administrator activities, I assume it is a good idea to work with
substr(session_id(), 0, 32);

>> - Can I safely expect $_SERVER['REMOTE_ADDR'] to deliver an IP address
>> of the format xxx.xxx.xxx.xxx, or can this also be an IPV6 address or
>> other?
>
> Unlike other comments, $_SERVER['REMOTE_ADDR]' cannot be forged in a
> useful manner. It comes directly from the ip header. It is also the ip
> address where the response would be sent. And while theoretically it
> could be forged, this requires hacking into the ip stack itself, not
> just a simple script or browser change - much more complicated than
> forging some of the other header values (like HTTP_REFERER). And it's
> really only useful for a DOS attack.
>
> But this can can be an IPV6 address if/when your hosting company goes
> that way.
To be honest, I never understood what is the point in collecting this
value at all, it just had been there in the first sample script I got
from my first PHP teacher years ago...

Thanks a lot for your helpful info!
Markus

Markus wrote:
> Jerry Stuckle schrieb:
>>> - Is a PHP session id always 32 characters long (if it is generated
>>> normally with session_start() of course), or can it's format vary due
>>> to PHP versions or configurations (I work in shared hosting
>>> envirnoments)?
>>
>> Currently it's 32 characters long. That's not to say it can't change
>> in future releases.
> So as I use it only for temporary data, such as shopping cart orders or
> administrator activities, I assume it is a good idea to work with
> substr(session_id(), 0, 32);

If you try to insert a longer string into the database than the column allows,
it will automatically be turnicated to the max length for the column, so you
don't have to use substr more when you compare the two values. Of you just
assume it's 32 characters long until the day you notice it don't anymore work,
when you ALTER the table to give more space for session id's.


>>> - Can I safely expect $_SERVER['REMOTE_ADDR'] to deliver an IP
>>> address of the format xxx.xxx.xxx.xxx, or can this also be an IPV6
>>> address or other?
>
> To be honest, I never understood what is the point in collecting this
> value at all, it just had been there in the first sample script I got
> from my first PHP teacher years ago...

The vast majority of users will have one and the same IP-number each time they
request a page during the same session, so you can use that ip-number to check
if the request comes from the same machine or not, it you get another ip, you
can assume that someone has managed to sniff the session id and trying to take
over that session, then you could terminate the session and request for the
user to login once more.

If you feel it's overkill, then remove the whole thing, no point in keeping a
IP-number in a database if you not gona use it.

--

//Aho

Markus wrote:
> Jerry Stuckle schrieb:
>>> - Is a PHP session id always 32 characters long (if it is generated
>>> normally with session_start() of course), or can it's format vary due
>>> to PHP versions or configurations (I work in shared hosting
>>> envirnoments)?
>>
>> Currently it's 32 characters long. That's not to say it can't change
>> in future releases.
> So as I use it only for temporary data, such as shopping cart orders or
> administrator activities, I assume it is a good idea to work with
> substr(session_id(), 0, 32);
>

Why even worry about the session id? Just let PHP handle it. You don't
want to store the session id in a database - the data will be gone soon,
anyway. Then you're left with a session id in the database but no
session to go with it.

>>> - Can I safely expect $_SERVER['REMOTE_ADDR'] to deliver an IP
>>> address of the format xxx.xxx.xxx.xxx, or can this also be an IPV6
>>> address or other?
>>
>> Unlike other comments, $_SERVER['REMOTE_ADDR]' cannot be forged in a
>> useful manner. It comes directly from the ip header. It is also the
>> ip address where the response would be sent. And while theoretically
>> it could be forged, this requires hacking into the ip stack itself,
>> not just a simple script or browser change - much more complicated
>> than forging some of the other header values (like HTTP_REFERER). And
>> it's really only useful for a DOS attack.
>>
>> But this can can be an IPV6 address if/when your hosting company goes
>> that way.
> To be honest, I never understood what is the point in collecting this
> value at all, it just had been there in the first sample script I got
> from my first PHP teacher years ago...
>
> Thanks a lot for your helpful info!
> Markus


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex [at] attglobal.net
==================

J.O. Aho wrote:
> Markus wrote:
>> Jerry Stuckle schrieb:
>>>> - Is a PHP session id always 32 characters long (if it is generated
>>>> normally with session_start() of course), or can it's format vary
>>>> due to PHP versions or configurations (I work in shared hosting
>>>> envirnoments)?
>>>
>>> Currently it's 32 characters long. That's not to say it can't change
>>> in future releases.
>> So as I use it only for temporary data, such as shopping cart orders
>> or administrator activities, I assume it is a good idea to work with
>> substr(session_id(), 0, 32);
>
> If you try to insert a longer string into the database than the column
> allows, it will automatically be turnicated to the max length for the
> column, so you don't have to use substr more when you compare the two
> values. Of you just assume it's 32 characters long until the day you
> notice it don't anymore work, when you ALTER the table to give more
> space for session id's.
>
>
>>>> - Can I safely expect $_SERVER['REMOTE_ADDR'] to deliver an IP
>>>> address of the format xxx.xxx.xxx.xxx, or can this also be an IPV6
>>>> address or other?
>>
>> To be honest, I never understood what is the point in collecting this
>> value at all, it just had been there in the first sample script I got
>> from my first PHP teacher years ago...
>
> The vast majority of users will have one and the same IP-number each
> time they request a page during the same session, so you can use that
> ip-number to check if the request comes from the same machine or not, it
> you get another ip, you can assume that someone has managed to sniff the
> session id and trying to take over that session, then you could
> terminate the session and request for the user to login once more.
>

Mostly true. But man users can change IP addresses each time because
they are using a pool of proxy servers. AOL is a great example of this,
but there are others.

And most corporations have a firewall and everyone behind the firewall
uses the same IP address. So you could have hundreds or even thousands
of people using the same IP address.

> If you feel it's overkill, then remove the whole thing, no point in
> keeping a IP-number in a database if you not gona use it.
>

Sessions are not security. If you need security, use a secure protocol.
Then you won't have a problem with sniffing session id's.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex [at] attglobal.net
==================

Jerry Stuckle schrieb:
>> So as I use it only for temporary data, such as shopping cart orders
>> or administrator activities, I assume it is a good idea to work with
>> substr(session_id(), 0, 32);
>>
>
> Why even worry about the session id? Just let PHP handle it. You don't
> want to store the session id in a database - the data will be gone soon,
> anyway. Then you're left with a session id in the database but no
> session to go with it.

Ooops... this is indeed a remainer from the times when I handled
sessions manually. Thanks for pointing this out!

Markus

Jerry Stuckle schrieb:
> J.O. Aho wrote:
>>> To be honest, I never understood what is the point in collecting this
>>> value at all, it just had been there in the first sample script I got
>>> from my first PHP teacher years ago...
>>
>> The vast majority of users will have one and the same IP-number each
>> time they request a page during the same session, so you can use that
>> ip-number to check if the request comes from the same machine or not,
>> it you get another ip, you can assume that someone has managed to
>> sniff the session id and trying to take over that session, then you
>> could terminate the session and request for the user to login once more.
>>
>
> Mostly true. But man users can change IP addresses each time because
> they are using a pool of proxy servers. AOL is a great example of this,
> but there are others.
>
> And most corporations have a firewall and everyone behind the firewall
> uses the same IP address. So you could have hundreds or even thousands
> of people using the same IP address.
>
>> If you feel it's overkill, then remove the whole thing, no point in
>> keeping a IP-number in a database if you not gona use it.
>>
>
> Sessions are not security. If you need security, use a secure protocol.
> Then you won't have a problem with sniffing session id's.

These are interesting points. The application is intended to be used in
various shared-hosting based environments; the choice of the protocol is
not part of it. But I just thought about introducing some kind of
low-level security by adding an ip check as an option, which can be
turned off if the administators work in an environment where the ip is
likely to change during the session.

Jerry Stuckle schrieb:
>> So as I use it only for temporary data, such as shopping cart orders
>> or administrator activities, I assume it is a good idea to work with
>> substr(session_id(), 0, 32);
>>
>
> Why even worry about the session id? Just let PHP handle it. You don't
> want to store the session id in a database - the data will be gone soon,
> anyway. Then you're left with a session id in the database but no
> session to go with it.

Ooops... this is indeed a remainer from the times when I handled
sessions manually. Thanks for pointing this out!

Markus

Jerry Stuckle schrieb:
> J.O. Aho wrote:
>>> To be honest, I never understood what is the point in collecting this
>>> value at all, it just had been there in the first sample script I got
>>> from my first PHP teacher years ago...
>>
>> The vast majority of users will have one and the same IP-number each
>> time they request a page during the same session, so you can use that
>> ip-number to check if the request comes from the same machine or not,
>> it you get another ip, you can assume that someone has managed to
>> sniff the session id and trying to take over that session, then you
>> could terminate the session and request for the user to login once more.
>>
>
> Mostly true. But man users can change IP addresses each time because
> they are using a pool of proxy servers. AOL is a great example of this,
> but there are others.
>
> And most corporations have a firewall and everyone behind the firewall
> uses the same IP address. So you could have hundreds or even thousands
> of people using the same IP address.
>
>> If you feel it's overkill, then remove the whole thing, no point in
>> keeping a IP-number in a database if you not gona use it.
>>
>
> Sessions are not security. If you need security, use a secure protocol.
> Then you won't have a problem with sniffing session id's.

These are interesting points. The application is intended to be used in
various shared-hosting based environments; the choice of the protocol is
not part of it. But I just thought about introducing some kind of
low-level security by adding an ip check as an option, which can be
turned off if the administators work in an environment where the ip is
likely to change during the session.

>Why even worry about the session id? Just let PHP handle it. You don't
>want to store the session id in a database - the data will be gone soon,
>anyway. Then you're left with a session id in the database but no
>session to go with it.

I'd prefer to use a session save handler and store all the session
data in a database rather than in a bunch of little files in a
directory. (Although, generally, letting PHP handle most details
of sessions works well.) For one thing, if I want my sessions to
expire *RELIABLY* on time, something like:

delete from sessiontable where lasthittime < subdate(now(), interval 4 hour);
run every 10 minutes (Or better, the session restore handler can simply
not find the existing session record if it's even one second over expired.)

seems to operate much quicker than looking at file stamps on a lot
of session files every 10 minutes. Clearing all the sessions on
reboot is also much faster. And sometimes the database entries are
more convenient to deal with than little files if you're trying to
debug something.

Should you have a reason for an admin page that lists currently
logged-in users, fetching that info out of a database may be much
easier than looking at lots of little files.

>>>> - Can I safely expect $_SERVER['REMOTE_ADDR'] to deliver an IP
>>>> address of the format xxx.xxx.xxx.xxx, or can this also be an IPV6
>>>> address or other?

If your server is on an IPv6 network, there may well not be any
IPv4 address that corresponds, so it would have to give you an IPv6
address or something useless.

>>> Unlike other comments, $_SERVER['REMOTE_ADDR]' cannot be forged in a
>>> useful manner. It comes directly from the ip header. It is also the
>>> ip address where the response would be sent. And while theoretically
>>> it could be forged, this requires hacking into the ip stack itself,
>>> not just a simple script or browser change - much more complicated
>>> than forging some of the other header values (like HTTP_REFERER). And
>>> it's really only useful for a DOS attack.
>>>
>>> But this can can be an IPV6 address if/when your hosting company goes
>>> that way.
>> To be honest, I never understood what is the point in collecting this
>> value at all, it just had been there in the first sample script I got
>> from my first PHP teacher years ago...

The IP address and timestamp are useful in making complaints to
ISPs about their malicious users, especially when they DOS attack
you, and in making complaints to police when they use stolen credit
card numbers at your site.

>Why even worry about the session id? Just let PHP handle it. You don't
>want to store the session id in a database - the data will be gone soon,
>anyway. Then you're left with a session id in the database but no
>session to go with it.

I'd prefer to use a session save handler and store all the session
data in a database rather than in a bunch of little files in a
directory. (Although, generally, letting PHP handle most details
of sessions works well.) For one thing, if I want my sessions to
expire *RELIABLY* on time, something like:

delete from sessiontable where lasthittime < subdate(now(), interval 4 hour);
run every 10 minutes (Or better, the session restore handler can simply
not find the existing session record if it's even one second over expired.)

seems to operate much quicker than looking at file stamps on a lot
of session files every 10 minutes. Clearing all the sessions on
reboot is also much faster. And sometimes the database entries are
more convenient to deal with than little files if you're trying to
debug something.

Should you have a reason for an admin page that lists currently
logged-in users, fetching that info out of a database may be much
easier than looking at lots of little files.

>>>> - Can I safely expect $_SERVER['REMOTE_ADDR'] to deliver an IP
>>>> address of the format xxx.xxx.xxx.xxx, or can this also be an IPV6
>>>> address or other?

If your server is on an IPv6 network, there may well not be any
IPv4 address that corresponds, so it would have to give you an IPv6
address or something useless.

>>> Unlike other comments, $_SERVER['REMOTE_ADDR]' cannot be forged in a
>>> useful manner. It comes directly from the ip header. It is also the
>>> ip address where the response would be sent. And while theoretically
>>> it could be forged, this requires hacking into the ip stack itself,
>>> not just a simple script or browser change - much more complicated
>>> than forging some of the other header values (like HTTP_REFERER). And
>>> it's really only useful for a DOS attack.
>>>
>>> But this can can be an IPV6 address if/when your hosting company goes
>>> that way.
>> To be honest, I never understood what is the point in collecting this
>> value at all, it just had been there in the first sample script I got
>> from my first PHP teacher years ago...

The IP address and timestamp are useful in making complaints to
ISPs about their malicious users, especially when they DOS attack
you, and in making complaints to police when they use stolen credit
card numbers at your site.